Repurpose of Existing Modules (Help needed!)

Hello,

I have a question regarding the reuse of existing Modules I have several project that are basically the same design about 80-90% similarities among the projects. Currently we are taking an existing database and repurposing it by making a copy then modifing it to meet the needs of that project. I was wondering is there a better way of maintaining the commonalities in one location while implementing the differences among the projects. I know some companies are doing this. I am just looking for ideas how to implement this. I know with the next generation of DOORS they are going to make this a key feature, but how would you go about implementing this in DOORS 9.x? Thank you.

-Jim
SystemAdmin - Thu Jan 19 22:30:15 EST 2012

Re: Repurpose of Existing Modules (Help needed!)
Mathias Mamsch - Fri Jan 20 10:04:44 EST 2012

Hi Jim,

that is a real complex issue. There are several use cases, that refer to what you call "repurpose". The first thing is parallel development. People like to start working on a follow up issue, while they are not finished with the old issue yet (for the same module!). The other use case is variant management and implementing a development platform. The idea of "reuse" is to duplicate only what is necessary, to be able to change only in one place and make the change everywhere. But there are important 'buts' to consider:
  • do I want to make the change everywhere at the same time? (imagine your variant A is in the middle of a review, while variant B just wants to start with another issue)
  • what do I want to reuse? Normally in DOORS you have lots of attributes, like validation attributes, etc. which in some cases you will NOT want to reuse. E.g. if a feature is validated correctly in variant A and one decides that feature is also validated in variant B, then you probably still need to make a new validation if the implementation really fits variant B.

Implementations that tackle this problem have to deal with redundancy, which means duplication/copying your data. There are as far as I know three basic ways of handling the issue you describe. One extreme is to
You keep all your information in one place, duplicating only what is really necessary, inside your modules. That means if you have a requirement that changes from version 2 to version 3 or variant A to variant B you will duplicate the requirement and flag the one copy as applicable for version 2/variant A and the other requirement to be applicable for version 3/variant B. The big advantage is that you can do this natively with DOORS without any scripting. But it really gives you a lot of restraints on your process. To really be 100% clean with this approach, you would need to duplicate an object on all kinds of occasions. If you move it, if you make a review comment, etc. Because unless you duplicate it will really share its state with all other versions/variants. The next possible disadvantage is, that you need to decide immediately when you make a change, if it applies to all other variants/versions or not. You cannot even wait until validation! Because once you did the change, all variants versions will be changed, unless you duplicate. Keep in mind, that this will really only be problematic for maybe 5%-10% of the changes, most changes, like typos, etc. work fine with that approach. Another thing that has to be considered is traceability and reports. Seeing the contents for one version/variant will only work with filters. It might affect existing reporting, traceability, scripts that do not expect to see other stuff in the module. When duplicating an object you need to think about the in-links (which will need to be recreated on lower levels). Also baselining gets complicated, because you will never have a consistent state, since one variant / version will always be worked at, so you always have part of your module in an inconsistent state at time of the baseline. I have seen some projects work successfully with that approach.

The second approach is, to have mutiple modules, one with all the reuse parts and a couple of others with just the content of the variants / version differences. The obvious drawback is that you split up your data into multiple places, making possibly ALL other scripts like exports, reports or traceability much more complicated. It gets much more complex to handle the parts that are reused in each variant/version and the ones which are different in one or more versions/variants. Once you realize you cannot keep track, you will wind up at the solution you just mentioned

you copy your modules, including all reused parts. This seems to be total overkill since usually you have like 90% reuse and 10% differences, but it really enables you to:
  • have independend processes for your development process (like validation, etc.).
  • have independend access settings
  • have a complete view for each variant / version all the time
  • can choose the time at which to integrate one change to another version / variant

And you trade this all for an incredible merge overhead, that you only can handle using scripts. We implemented a complete branch & merge solution for DOORS which enabled you to keep copies of modules and interactively merge changes from one branch to another using a 3-way-merge (i.e. with conflict detection). This is a good solution to the problem, although it might not be necessary for each kind of reuse/parallel development use case. But it is really the only way that I know to a) let the users work with native DOORS, that is all filters, views, etc. and espcially existing scripts for reporting / exporting work like before b) decouple the lifecycle and development process of all variants / versions. I have seen a lot of customers successfully work with "syncronization" scripts of all kinds. If you and your company are interested in a solution like this, we can get in contact.

Hope that lengthy answer helps you a bit with the decision, regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Repurpose of Existing Modules (Help needed!)
SystemAdmin - Sat Jan 21 17:26:18 EST 2012

Mathias Mamsch - Fri Jan 20 10:04:44 EST 2012
Hi Jim,

that is a real complex issue. There are several use cases, that refer to what you call "repurpose". The first thing is parallel development. People like to start working on a follow up issue, while they are not finished with the old issue yet (for the same module!). The other use case is variant management and implementing a development platform. The idea of "reuse" is to duplicate only what is necessary, to be able to change only in one place and make the change everywhere. But there are important 'buts' to consider:

  • do I want to make the change everywhere at the same time? (imagine your variant A is in the middle of a review, while variant B just wants to start with another issue)
  • what do I want to reuse? Normally in DOORS you have lots of attributes, like validation attributes, etc. which in some cases you will NOT want to reuse. E.g. if a feature is validated correctly in variant A and one decides that feature is also validated in variant B, then you probably still need to make a new validation if the implementation really fits variant B.

Implementations that tackle this problem have to deal with redundancy, which means duplication/copying your data. There are as far as I know three basic ways of handling the issue you describe. One extreme is to
You keep all your information in one place, duplicating only what is really necessary, inside your modules. That means if you have a requirement that changes from version 2 to version 3 or variant A to variant B you will duplicate the requirement and flag the one copy as applicable for version 2/variant A and the other requirement to be applicable for version 3/variant B. The big advantage is that you can do this natively with DOORS without any scripting. But it really gives you a lot of restraints on your process. To really be 100% clean with this approach, you would need to duplicate an object on all kinds of occasions. If you move it, if you make a review comment, etc. Because unless you duplicate it will really share its state with all other versions/variants. The next possible disadvantage is, that you need to decide immediately when you make a change, if it applies to all other variants/versions or not. You cannot even wait until validation! Because once you did the change, all variants versions will be changed, unless you duplicate. Keep in mind, that this will really only be problematic for maybe 5%-10% of the changes, most changes, like typos, etc. work fine with that approach. Another thing that has to be considered is traceability and reports. Seeing the contents for one version/variant will only work with filters. It might affect existing reporting, traceability, scripts that do not expect to see other stuff in the module. When duplicating an object you need to think about the in-links (which will need to be recreated on lower levels). Also baselining gets complicated, because you will never have a consistent state, since one variant / version will always be worked at, so you always have part of your module in an inconsistent state at time of the baseline. I have seen some projects work successfully with that approach.

The second approach is, to have mutiple modules, one with all the reuse parts and a couple of others with just the content of the variants / version differences. The obvious drawback is that you split up your data into multiple places, making possibly ALL other scripts like exports, reports or traceability much more complicated. It gets much more complex to handle the parts that are reused in each variant/version and the ones which are different in one or more versions/variants. Once you realize you cannot keep track, you will wind up at the solution you just mentioned

you copy your modules, including all reused parts. This seems to be total overkill since usually you have like 90% reuse and 10% differences, but it really enables you to:
  • have independend processes for your development process (like validation, etc.).
  • have independend access settings
  • have a complete view for each variant / version all the time
  • can choose the time at which to integrate one change to another version / variant

And you trade this all for an incredible merge overhead, that you only can handle using scripts. We implemented a complete branch & merge solution for DOORS which enabled you to keep copies of modules and interactively merge changes from one branch to another using a 3-way-merge (i.e. with conflict detection). This is a good solution to the problem, although it might not be necessary for each kind of reuse/parallel development use case. But it is really the only way that I know to a) let the users work with native DOORS, that is all filters, views, etc. and espcially existing scripts for reporting / exporting work like before b) decouple the lifecycle and development process of all variants / versions. I have seen a lot of customers successfully work with "syncronization" scripts of all kinds. If you and your company are interested in a solution like this, we can get in contact.

Hope that lengthy answer helps you a bit with the decision, regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Hello,

Thank you for your response.

The way I was thinking of implementing this was to create a new Project called B that is duplicate of A while linking them together (object to object) through a Link Module called "Master Copy". And in this way we could use “Suspect Links” to monitor changes between the projects therefore each project could determine what the impact is to that given project and determine whether to implement the change(s) while allowing the additional design differences. The only think is how would I prevent someone from deleting (Purging) an object in Project A that is also linked to Project B (trigger?)? By using a links from project A to B this would eliminate the need to verify the same object in Project B if the object has not changed this can be done using “Suspect Links”. Yes we would still have to validate the project independently. Does anyone see any flaws in my logic??

Thank you,
Jim

Re: Repurpose of Existing Modules (Help needed!)
llandale - Sat Jan 21 17:51:40 EST 2012

SystemAdmin - Sat Jan 21 17:26:18 EST 2012
Hello,

Thank you for your response.

The way I was thinking of implementing this was to create a new Project called B that is duplicate of A while linking them together (object to object) through a Link Module called "Master Copy". And in this way we could use “Suspect Links” to monitor changes between the projects therefore each project could determine what the impact is to that given project and determine whether to implement the change(s) while allowing the additional design differences. The only think is how would I prevent someone from deleting (Purging) an object in Project A that is also linked to Project B (trigger?)? By using a links from project A to B this would eliminate the need to verify the same object in Project B if the object has not changed this can be done using “Suspect Links”. Yes we would still have to validate the project independently. Does anyone see any flaws in my logic??

Thank you,
Jim

There is no good solution. Yours may be the most realistic solution.

You would want to link FROM the new subordinate project TO to the master project. This gives the subordinate folks control over the links, for example if there is a master requirement this sub-project doesn't need, they would unlink then delete that requirement. If the links were in the other direction, sub folks would need to get "permission" from the master folks to delete their link.

This would prevent the Master folks from deleting a Master requirement that is used by some Subordinate; since that Master object would have an incoming link. You would coordinate that by unlinking all the Subordinate requirements, somehow re-marking them as "local to this project", and thus allow the master folks to remove their master requirement.

Coordinating all these links may prove impossible to manage. I may be inclined to have a "Master ID" attribute containing the ObjID (or Master ID) of the associated master requirement, if any. Some DXL would look at that, find that requirement, then display the differences, effectively doing your "Suspect Links" work.

-Louie